Contributions à la sécurité des Java Card

La Java Card est aujourd’hui le type de cartes à puce le plus déployé dans le milieu bancaire ou dans la téléphonie mobile. Outres la présence de nombreuses contre-mesures physiques pour protéger le microprocesseur contre les attaques externes, la machine virtuelle Java Card possède un ensemble de mécanismes (comme le vérificateur de bytecode et le pare-feu) qui, combinés avec le typage du langage Java, offrent des propriétés d’isolation forte des applications (applets) vis-à-vis de l’exécution de la machine virtuelle Java Card.Mais l’évolution des attaques logicielles par confusion de type et par des moyens physiques a montré des limitations au modèle d’isolation de la machine virtuelle. Dans un premier temps, plusieurs travaux montrent des nouvelles menaces logiques, physiques et hybrides afin de lever des secrets enfouis dans des instances de Java Card en exploitant les applications chargées comme cibles et vecteurs d’attaque. Par la suite, plusieurs stratégies de contre-mesures sont construites selon deux points de vue. D’une part des protections réactives (contre les attaques en fautes) et proactives (par mise à jour dynamique) sont intégrées dans la machine virtuelle Java Card. D’autre part, des solutions d’analyse de code permettant d’aider le développeur sont évaluées afin de renforcer la sécurité des applets contre des faiblesses de développement ou les exploitations possibles du bytecode par des attaques en faute

Combined Software and Hardware Attacks on the Java Card Control Flow

Part 7: Java Card SecurityInternational audienceThe Java Card uses two components to ensure the security of its model. On the one hand, the byte code verifier (BCV) checks, during an applet installation, if the Java Card security model is ensured. This mechanism may not be present in the card. On the other hand, the firewall dynamically checks if there is no illegal access. This paper describes two attacks to modify the Java Card control flow and to execute our own malicious byte code. In the first attack, we use a card without embedded security verifier and we show how it is simple to change the return address of a current function. In the second attack, we consider the hypothesis that the card embeds a partial implementation of a BCV. With the help of a laser beam, we are able to change the execution flow

Pip, un proto-noyau fait pour renforcer la sécurité dans les objets connectés

National audienceAvec le développement et l'évolution de plus en plus rapides des objets connectés (Internet of Things), la sécurité et la confidentialité sont devenues des propriétés désirées par chaque constructeur dans leurs appareils, moyennant un coût, en termes de performances, moindre. En tant que moyen d'assurer mathématiquement les propriétés désirées, la preuve formelle a fait son entrée dans le domaine du développement noyau. Cependant, la vérification formelle nécessite beaucoup de travail et impose plusieurs contraintes : la moindre modification du modèle ou du code provoque de nombreuses modifications sur la preuve. Comme réponse à ce problème, nous présentons Pip, un proto-noyau n'assurant que la propriété voulue, l'isolation mémoire, par le biais d'une base de confiance prouvée, tout en laissant le code utilisateur gérer les fonctionnalités restantes

Cartes à puce : Attaques et contremesures

International audienceNous présentons dans cet article nos travaux de recherche traitant des attaques en fautes et des attaques logiques sur les cartes à puce, en particulier sur la Java Card. Nous introduisons en présentant la Java Card et ses mécanismes sécuritaires. Ensuite nous présentons les types d'attaques réalisées sur les cartes à puce et, nous présentons quelques contremesures de ces attaques et en particulier celles sur les attaques en fautes. Et nous terminons par la présentation de nos travaux sur l'outil de manipulation d'un format de fichier de la Java Card et des propositions d'autres contremesures pour les attaques en faute

Developing a trojan applet in a Smart Card

International audienc

Pip, un proto-noyau fait pour renforcer la sécurité dans les objets connectés

National audienceAvec le développement et l'évolution de plus en plus rapides des objets connectés (Internet of Things), la sécurité et la confidentialité sont devenues des propriétés désirées par chaque constructeur dans leurs appareils, moyennant un coût, en termes de performances, moindre. En tant que moyen d'assurer mathématiquement les propriétés désirées, la preuve formelle a fait son entrée dans le domaine du développement noyau. Cependant, la vérification formelle nécessite beaucoup de travail et impose plusieurs contraintes : la moindre modification du modèle ou du code provoque de nombreuses modifications sur la preuve. Comme réponse à ce problème, nous présentons Pip, un proto-noyau n'assurant que la propriété voulue, l'isolation mémoire, par le biais d'une base de confiance prouvée, tout en laissant le code utilisateur gérer les fonctionnalités restantes

Evolution du modèle du proto-noyau PIP vers les architectures SMP

International audienc

Porting the Pip proto-kernel's model to multi-core environments

International audienc

Genetic Algorithm for DWCET Evaluation on Complex Platform

International audienceIndustrial approach to evaluate the WCET of a software test object is to benchmark it several times bare metal until enough confidence. But complexity of modern hardware and use of real-time operating system to execute multiple tasks on the top of the hardware increase the difficulty to obtain strong WCET guarantee. We propose GACC (Genetic Algorithm with Complex Contexts), a framework to evaluate the WCET of a test object using genetic algorithm but extended with the context information outside of the test software object, that is including kernel, other tasks and hardware states. As presented, this approach requires the need of coherent contexts without modeling them. Based on the need for fast evaluation, GACC records andreplays hardware and software contexts, hence constructing a library of valid contexts which are used during execution of GA to find interesting solution candidates

Contexte d’exécution dans la recherche de pire temps d’exécution d’un système complexe

International audienceL’estimation du pire temps d’exécution (Worst Case Execution Time ou WCET), c’est-à-dire le temps d’exécution maximal de certaines tâches critiques d’un système embarqué, est généralement effectuée sur une plate-forme matérielle embarquée dédiée, sans système d’exploitation (i.e. bare-metal). Mais la nécessité de réduire le coût de certification et la complexité grandissante du logiciel motivent le déploiement de systèmes d’exploitation temps-réel (RTOS) ou d’hyperviseurs pour réduire les dépendances entre les tâches (ou charges logicielles). Cette avancée amène une plus grande difficulté d’évaluation du WCET des appels (systèmes) vers le RTOS car ces architectures entraînent une explosion du nombre d’états du système indépendamment de la tâche testée. Dans ce papier nous développons dans un premier temps la notion de contexte global logiciel et matériel du système dans l’évaluation du WCET d’une tâche. Pour permettre une évaluation rapide d’une tâche en tenant compte du système sous-jacent, nous proposons d’étendre les algorithmes génétiques d’évaluation de WCET pour intégrer le contexte logiciel et matériel dans la définition du chromosome